NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/366

Text File | 1996-08-06 | 4.6 KB | 107 lines

Path: engnews1.Eng.Sun.COM!taumet!clamage
From: [e-mail] (James Kanze US/ESC 60/3/141 #40763)
Newsgroups: comp.std.c++
Subject: Re: basic_string& operator=(const basic_string&)
Date: 8 Feb 1996 16:30:33 GMT
Organization: SEL
Sender: [e-mail]
Approved: [e-mail] (comp.std.c++)
Message-ID: <[e-mail]>
References: <4f81p2$[e-mail]>
NNTP-Posting-Host: taumet.eng.sun.com
Content-Type: text
In-Reply-To: "john's message of 06 Feb 1996 10:28:03 PST
Apparently-To: [e-mail]
Content-Length: 3853
X-Lines: 83
Originator: clamage@taumet

In article <4f81p2$[e-mail]> "john (j.d.) hickin"
<[e-mail]> writes:

|> The following was taken from a copy of the DWP:

|>   basic_string<charT,traits,Allocator>&
|>       operator=(const basic_string<charT,traits,Allocator>& str);

|>   Effects:
|>     If *this and str are not the same object, modifies *this such that:

|>                       Table 7--operator=(str) effects

|>              +-------------------------------------------------+
|>              | Element                    Value                |
|>              +-------------------------------------------------+
|>              |data()       points at the first element  of  an |
|>              |             allocated  copy  of  the  the array |
|>              |             whose first element is  pointed  at |
|>              |             by str.size()                       |
|>              |size()       str.size()                          |
|>              |capacity()   a value at least as large as size() |
|>              +-------------------------------------------------+
|>     If *this and str are the same object, the member has no effect.
|>   Returns:
|>     *this

|> Aside from a seeming typographical error in the Value column for Element data()
|> (... by str.data() ?) the wording of this seems to rule out a counted pointer
|> representation.

|> Is my interpretation correct?

Well, it says `allocated copy', not `newly allocated copy', so
strictly speaking...:-).  Still, what you are saying would seem to be
the intent.

Note that in any case, the basic template cannot use a countedd
pointer representation, or only with extreme difficulty, because of
the allocator arguments to the constructors.  (Different instances may
be allocated from different memory pools.)  I believe, however, that
the intent is that the implementation provide optimized
specializations for the `standard' cases (char and wchar_t, default
traits and allocator).  The standard guarantees that all instances of
the default allocator are, in effect, the same; this provides the
necessary loop-hole for reference counting with regards to the
allocator.

In many ways, calling the allocator is a side issue (although it is an
observable side effect when a user defined allocator is used); what is
important is the validity of addresses obtained from c_str, data, and
expressions like &s[ i ].  I feel that these are really separate
issues, at least from a standards point of view.  (From the
implementation point of view, of course, I cannot imagine a case where
I reallocate but do not invalidate the addresses.  The reverse is
*not* necessarily true, however.)

The current wording of the standard in fact guarantees nothing.  For
example, consider the following:

    string              s( "abc" ) ;
    s.reserve( 100 ) ;              //  should be enough
    char const*         ps( s.data() ) ;
    s.remove( 0 , 1 ) ;
    assert( *ps == 'b' ) ;

Is the assert guaranteed.  According to the present wording, all that
is guaranteed is that s.remove did not reallocate; I seen nothing in
the draft standard which would preclude the implementation from simply
playing tricks with the start pointer, however, leaving ps pointing to
the `a' (that is no longer in the string).

I do not know whether this is intended or not.  Personally, I have no
problem with the above being undefined, as long as it is explicitly
stated that it is undefined (e.g.: all non-const functions may
invalidate any previously returned pointers, whether reallocation
occurs or not).
--
James Kanze         Tel.: [phone]        email: [e-mail]
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
                -- A la recherche d'une activitΘ dans une region francophone


[ comp.std.c++ is moderated.  Submission address: [e-mail].
  Contact address: [e-mail].  The moderation policy is
  summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]